Next generation telecommunications and networking systems are expected to support a wide range of use cases with varying requirements ranging from fully mobile devices to stationary Internet of Things (IoT) or fixed wireless broadband devices. The traffic pattern associated with many use cases for next generation systems is expected to consist of short or long bursts of data traffic with varying length waiting periods between transmissions. For such traffic it is important to optimize the state between the data bursts, often referred to as an inactive state, as well as the transition to active state, in which data transmissions are made.
Small data transmission is of considerable interest as a component of overall traffic pattern, as cumulated small data transmission traffic represents a significant proportion of the overall network traffic, owing in large part to the high market penetration of smartphones. The majority of overhead for small data transmission is the signaling overhead for radio connection setup which is required even before transmission of one small data block. The relatively large overhead for a small data transmission is a common issue for both Long Term Evolution (LTE) and the next generation New Radio Access Technology (NR).
In order to reduce signaling overhead and the associated processing load in the network for small data transmission, Service and System Aspects (SA)2 and Radio Access Network (RAN) Working Groups concluded that a solution for LTE would be introduced in Release 13, the solution allowing a Radio Resource Control (RRC) connection to be suspended and subsequently resumed, thus minimizing the need to go through the full signaling procedure for transitioning from an idle state RRC_IDLE to a connected state RRC_CONNECTED for small data transmissions. The Suspend/Resume procedure is applicable both to normal LTE User Equipments (UEs) and IoT UEs.
The RRC Suspend/Resume procedure is based on enhancements to the RRC_IDLE state making it possible to resume an RRC connection without needing to set the connection up again when the UE returns from an idle state, assuming that a majority of the time, a UE will return to connected state in a cell serviced by a node which has stored the RRC context for the UE. The RRC Suspend/Resume procedure uses a UE RRC context, also referred to as an Access Stratum (AS) context. The UE RRC context is stored both in the RAN and in the UE. When a UE initiates an RRC Resume procedure, for example to transmit small data, the eNB receiving the RRC Resume Request will either have the context available or will fetch it from another node where it was stored when the UE was suspended. The UE RRC context or AS Context contains information needed for the UE and network to resume the RRC connection. This includes security parameters such as encryption keys, parameters for Signaling Radio Bearers (SRBs) and Data Radio Bearers (DRBs) (Packet Data Convergence Protocol (PDCP) and Radio Link Control (RLC) configurations) and measurement configurations.
The RRC Suspend/Resume procedure is illustrated in FIG. 1 between a UE and an eNodeB (eNB). Referring to FIG. 1, the procedure starts with a Random Access request. This is partly required as the Uplink (UL) synchronization cannot be guaranteed as a result of UE inactivity (that is the suspension of the RRC connection) and the fact that the UE may have moved to a new position, requiring adjustment of the timing offset for UL synchronization, or may have moved to a new cell or tracking area.
Upon reception of Random Access Channel (RACH) preamble, the eNB sends a Re-activation Request (RAR) message include a timing advance (TA) value for UL timing and a grant for SRB0, which is needed for the RRC connection re-activation request transmission. The SRB0 is used to carry Common Control Channel (CCCH) signaling, without the support of security functionalities as is required for other types of SRBs and DRBs.
When the RRC connection re-activation request message is successfully transmitted to the UE (RRCConnectionResumeRequest, according to TS 36.331) the UE will activate its RRC context. From this point in the procedure, SRBs and DRBs are encrypted, as the activated UE RRC context contains configuration parameters for SRBs and DRBs (PDCP/RLC parameters), encryption keys and measurement configurations. The eNB also activates the UEs RRC context and replies with an RRC connection re-activation message to the UE (RRCConnectionResume). This message may also include grants for the DRB used for data transmission. Upon receiving this message the UE enters the RRC_CONNECTED state.
Finally, the UE responds with an RRC connection re-activation complete message and the UE is then ready for UL data transmission. When the UE has finished its transmission there will be signaling to in-activate the UEs RRC context and send the UE back to an inactive state again. This signaling may for example be triggered if the UE is inactive for a certain period of time.
It has been agreed that in the next generation NR there will be an inactive “state” with the following characteristics:                a/ CN/RAN connection is maintained        b/ AS context is stored in the RAN        c/ Network knows a UE's location within an area and the UE performs mobility within that area without notifying the network.        d/ RAN can trigger paging of UEs which are in the RAN controlled “inactive state”        e/ No dedicated resources        
In LTE Release 14, under the RRC light connection working item, the solution based on Suspend/Resume described above and illustrated in FIG. 1 appears to be evolving in the same direction as the NR inactive state, with very similar characteristics also being assumed for the UE when the RRC context is suspended. This is illustrated in FIG. 2.
In recent work, progress has been made on UE state assumptions for NR. It has been agreed that an “inactive” state will be introduced, in which a UE should be able to start data transfer with low delay (as dictated by RAN requirements). One of the open issues concerned data transmission when UEs are in the “inactive” state, with the question of whether data transfer is accomplished by the UE leaving the inactive state or can take place with the UE in the inactive state being held over for further study. This question has now been partially resolved, with agreement that in the inactive state there will be a mechanism where the UE first transitions to the full connected state in which data transmission can occur. However, for the special case of small data transmissions, a possibility for the UE to perform data transmission without state transition from the inactive state to the connected state is considered.